home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 9 / QRZ Ham Radio Callsign Database - Volume 9.iso / mac / files / p_term / ad16dis.exe / ARESDA10.PAP < prev    next >
Text File  |  1990-03-03  |  25KB  |  542 lines

  1.  
  2.                             ARES/Data UPDATE:
  3.         A PACKET RADIO DATABASE FOR EMERGENCY COMMUNICATIONS WITH
  4.                             CONFERENCE BRIDGE
  5.  
  6.                          W. E. Moerner, WN6I
  7.                           1003 Belder Drive
  8.                      San Jose, California  95120
  9.                             WN6I @ K3MC
  10.  
  11.                         Sharon Moerner, N6MWD
  12.                           1003 Belder Drive
  13.                      San Jose, California  95120
  14.                            N6MWD @ K3MC
  15.  
  16.                          David Palmer, N6KL
  17.                            248 Omira Drive
  18.                      San Jose, California  95123
  19.                      N6KL @ K3MC, CIS: 73357,3157
  20.  
  21.  
  22.                               INTRODUCTION
  23.  
  24. ARES/Data is a multiple-connect, multiple-port specialized bulletin board
  25. system with a conference bridge that is tailored to store and retrieve
  26. basic information about people, places, or things in an emergency or
  27. disaster.  The current program (Version 1.0) contains several enhancements
  28. not included in ARES/Data Version 0.1 [see Moerner, W.  E., & Palmer, D.
  29. (1988), ARES/Data:  A Packet Radio Database for Emergency Communications,
  30. Proceedings of the Seventh ARRL Computer Networking Conference, 141-144].
  31. [Note:  For those interested in the history of ARES/Data, see the above
  32. mentioned article and also see Moerner, W.  E., Moerner, S., & Palmer, D.
  33. (1987), Family Information Database for Emergency Responders, Proceedings
  34. of the Sixth ARRL Computer Networking Conference, 131-141.]
  35.  
  36. New features added to version 1.0 (beyond 0.1) include:
  37.  
  38. - Multiple ports (up to 4, with 8-32 simultaneous connects each)
  39.  
  40. - Support for DRSI PC*PA packet adapters
  41.  
  42. - Enhanced config file processing with startup files for each TNC
  43.  
  44. - Update of selected field in a record
  45.  
  46. - Import/Export facility
  47.  
  48. - List range in addition to list all
  49.  
  50. - Beacon facility
  51.  
  52. - Download file facility from a public directory
  53.  
  54. - Labels command, including a label for the message field
  55.  
  56. - Separate paths for database, index files, public directory
  57.  
  58. - Many enhancements for the sysop screen
  59.  
  60. - Improved error handling of disk full and disk errors
  61.  
  62.  
  63. The key idea behind ARES/Data is that it allows tracking of any needed
  64. information that can be organized as four 20-character fields plus an 80-
  65. character message for each record.
  66.  
  67. ARES/Data is a system designed for management of information during a
  68. widespread emergency that overloads normal communications channels.  The
  69. program is conceived to be flexible, so that it can be used without change
  70. for both small and large disasters to organize information about victims,
  71. evacuees, or even ham radio operators.  Examples of situations in which
  72. ARES/Data could be used include:
  73.  
  74. - Track victims of a multiple casualty incident sent to hospitals
  75.  
  76. - Track ham manpower availability / assignments
  77.  
  78. - Record evacuees and shelter enrollment
  79.  
  80. - Track floats in a parade
  81.  
  82. - Short-message database: Field1 = To Field2 = From Msg = 80 char. message
  83.  
  84. - House-by-House Damage Assessment
  85.  
  86. - DX Spotting (!)
  87.  
  88. - Etc.  !
  89.  
  90.  
  91.                              ARES/Data SYSTEM OVERVIEW
  92.  
  93. Briefly, ARES/Data may be regarded as a specialized, multiple-port,
  94. multiple-connect database with a specific command set tailored to the
  95. handling of information input, search, listing, and summary requests.  In
  96. addition, the system provides a full-featured conference bridge so that all
  97. connected stations may converse conveniently with one another.
  98.  
  99. The ARES/Data network is a star network with the ARES/Data database machine
  100. at the hub.  It looks something like this:
  101.  
  102.                     _______ARES/Data Database Machine_______
  103.                     |           |             |             |
  104.                     Port A      Port B       Port C        Port D
  105.                     |           |             |             |
  106.                     radio       radio         radio         radio
  107.                     ..          ...           ...           ....
  108.                     . .         . . .         . . .         . . . .
  109.                     . . .       .  .  .       .  .  .       .  .  . .
  110.                     . .   .     .  . .  .     .  . .  .     .  . .  . .
  111.                     P P    P    P  P P  P     P  P P  P     P  P P  P P
  112.  
  113. Each "P" represents a remotely-connected packet station which is connected
  114. to the ARES/Data database machine.  All the remotely-connected stations
  115. have shared access to the data in the system.  In particular, the packet
  116. operators can utilize two groups of functions provided by ARES/Data which
  117. are described in detail in this file:
  118.  
  119.     I.  send/receive status requests and current information to/from the
  120.         ARES/Data database station
  121.  
  122.    II.  send/receive short messages to/from other remotely connected
  123.         stations or the sysop (Conference Bridge)
  124.  
  125. As can be seen, there are three major elements to the ARES/Data system:
  126.  
  127.     o ARES/Data software and database (at one centrally located computer)
  128.     o Remote packet stations connected to the central node
  129.     o Conference Bridge
  130.  
  131. The central element of the ARES/Data system is the ARES/Data database
  132. program running on an IBM Personal Computer or compatible.  The ARES/Data
  133. program collects and collates current information about people (or other
  134. items) according to the needs of the incident, and maintains the database
  135. on floppy disk or hard disk at this central computer.  The sysop at this
  136. computer can execute all database functions.
  137.  
  138. If remote access is desired to the information in the database, this
  139. computer may be connected to a packet radio channel or channels through up
  140. to four ports, each of which can be either a TNC with WA8DED firmware or a
  141. DRSI PC*PA packet radio adapter.  In this manner, other remote packet
  142. stations can connect to the ARES/Data machine and thus gain access to the
  143. stored information.  This information can be updated or queried by the
  144. sysop or any of the remote packet stations that are all simultaneously
  145. connected to the main database station.
  146.  
  147. At any time, the sysop and any of the connected stations can communicate
  148. with each other by using a simple "tell" command.  This "conference bridge"
  149. actually implements a star-shaped network in which the central database
  150. station relays all of the message traffic.  (As noted, the central element
  151. of the ARES/Data system is the computer on which the ARES/Data program is
  152. running.)
  153.  
  154.                                 Hardware Requirements
  155.  
  156. The ARES/Data program will run on any IBM Personal Computer or
  157. IBM-compatible system running DOS V.  3.2 or later.  Although it can be run
  158. on a computer having about 400 KB of memory or more with at least one
  159. floppy disk, a hard disk is recommended as it increases the allowable size
  160. of the database and improves performance.  [IBM is a registered trademark
  161. of International Business Machines Corporation.]
  162.  
  163. To enable the remote packet access features, the sysop also needs at least
  164. a (i) DRSI PC*PA packet adapter, cable, and transceiver or (ii) RS-232
  165. serial port, TNC containing WA8DED firmware (TNC-1, TNC-2, AEA PK-87, AEA
  166. PK-88), cable, and transceiver.  NOTE:  the remotely connecting packet
  167. stations may use ANY AX.25 TNC.
  168.  
  169.  
  170.               DESCRIPTION and OPERATION of the ARES/Data SYSTEM V. 1.0
  171.  
  172.                                 The ARES/Data Program
  173.  
  174. The ARES/Data software was written by W.  E.  Moerner, WN6I, and David
  175. Palmer, N6KL, with the ideas and support of a committee of hams from the
  176. Santa Clara County Amateur Radio Emergency Service (ARES).  It is a
  177. copyrighted program, available without charge to anyone interested.  The
  178. authors cannot and will not accept remuneration for this program which is
  179. provided as a public service only.  The ARES/Data program is written in
  180. Turbo Pascal Version 5.5, and uses Turbo Database Toolbox for management
  181. and indexing of its B-plus structured tree.  [Turbo Pascal and Turbo
  182. Database Toolbox are trademarks of Borland International, Inc.]
  183.  
  184. ARES/Data may be run in either of two modes:  (i) stand- alone with no TNC
  185. support and no remote access, or (ii) by changing the configuration file,
  186. the program will control one or more TNCs to allow multiple, simultaneous
  187. remote connections.  Use of WA8DED firmware with the central computer is
  188. necessary because WA8DED host mode is used for communication between the
  189. computer and the TNC.  WA8DED firmware is currently available for the TAPR
  190. TNC-1 and TNC-2 as well as the AEA PK-87.  We emphasize that NO REQUIREMENT
  191. IS PLACED ON THE OTHER TNC'S CONNECTED TO THE ARES/Data DATABASE MACHINE,
  192. except that they use AX.25 link-layer protocol.
  193.  
  194.              General Rules for Current Information Input/Search Requests
  195.  
  196. All basic commands can be entered either at the main ARES/Data keyboard or
  197. at any one of the remotely connected packet stations.  The operator at the
  198. main ARES/Data keyboard (the "sysop") has an additional set of commands
  199. that allow direct communication with the TNC, the printing of a log,
  200. backups, and disk report files.
  201.  
  202. ARES/Data organizes the incoming data into "records", which can be viewed
  203. as a group of pieces of information about some particular person, place, or
  204. thing.  Each record is given a unique "record number" by the program.  Each
  205. record consists of four main items or "fields" plus a message item.  The
  206. information in the four main fields can be used as keywords for searching
  207. as required.
  208.  
  209.                         Syntax for Current Information Input
  210.  
  211.                        field1,field2,field3,field4,message<cr>
  212.  
  213.                               (<cr> means carriage return)
  214.  
  215. To add a record to the database, the operator simply enters (in order) the
  216. four fields and any message, separating each field with a comma.  Within a
  217. field, leading and trailing blanks are ignored, but imbedded blanks ARE
  218. significant.  If no value is desired for a particular field, just skip the
  219. field by adding an extra comma.  The database will fill that field with ten
  220. blank characters.
  221.  
  222.     Fields 1 through 4
  223.  
  224. The four main fields are totally general.  Each can have up to 20
  225. characters, with imbedded blanks.  Entries can be in upper or lower case,
  226. or a mixture, but are converted to UPPER case before being stored in the
  227. database.  The meaning of each field is defined at the beginning of the
  228. event depending upon the nature of the event.  The sysop can issue a
  229. "labels" command that will give specific names to each of the four fields
  230. to help the operators remember what they mean.  Similarly, the remote
  231. packet operator can type "labels<cr>" to see the current label definitions.
  232.  
  233.     Message
  234.  
  235. MESSAGE is an optional, free-form field that can be up to 80 characters in
  236. length.  It could contain a message, a phone number, an address, or other
  237. information deemed useful for the incident.  The distinction between the
  238. "fields" and the "message" is that the "fields" are organized internally by
  239. the program so that the packet operator can request searches and summaries
  240. on the information in any one of the four fields.  Searches and summaries
  241. cannot be performed on the information in the message field.
  242.  
  243.     Examples of Data Input with Sample Responses from ARES/Data
  244.  
  245.          85553195,joe,12,sj34<cr>
  246.       response->   1040: data input accepted, #234.
  247.  
  248.          Johnson,Mary,93445,sj13, home 2333 Alsace Ln SJ 617-555-2368<cr>
  249.       response->   2134: data input accepted, #114.
  250.  
  251. All of the input information is stored in the database as a record of the
  252. status and location of a particular person, place, or thing at a particular
  253. time and date.  The time and date are added automatically by the ARES/Data
  254. program.  Further STATUS INPUT packets for the same person, place, or thing
  255. will also be saved in the database.  The time and date identifies the most
  256. recent information.
  257.  
  258.                           Correcting and/or Updating Information
  259.  
  260. Two options are available if incorrect information is entered into the
  261. database or if the information in a particular record has changed.
  262.  
  263.     Deleting an Entire Record
  264.  
  265. You can ask the sysop to delete the bad entry by typing a message to
  266. him/her, such as:
  267.  
  268.                     tell sysop ooops, typo. pse delete #234.<cr>
  269.  
  270. OR, if the sysop has enabled the remote delete feature, a remotely
  271. connected packet station can delete this by using the delete command:
  272.  
  273.                      d nnnn<cr>    (where nnnn = record number)
  274.  
  275. This function is always enabled at the sysop keyboard.  Its use by remotely
  276. connected packet stations is controlled initially by the configuration file
  277. during program startup.  Thereafter, the sysop can disable or enable this
  278. function as necessary.
  279.  
  280.  
  281.     Changing or Updating a Particular Field of a Particular Record
  282.  
  283.              The syntax for updating fieldm of record nnnn is:
  284.  
  285.                         #nnnn,m=new text for fieldm<cr>
  286.  
  287. For example, suppose it was desired to change the value in field3 of record
  288. 235 to "shelter 9".  This is done by typing:
  289.  
  290.                              #235,3=shelter 9<cr>
  291.  
  292. Note that when correcting or updating a single field like this, the time
  293. and date for the record are not changed.  ARES/Data responds by showing the
  294. old values for record 235, along with the newly updated values.
  295.  
  296.  
  297.                     Requesting Information from the ARES/Data Database
  298.  
  299. The packet operator can request several types of searches of the ARES/Data
  300. database.  S/he can request a search for a specific value of any one of the
  301. four main fields.  In this case, the ARES/Data program sends back to the
  302. packet operator a status report listing all entries in the database having
  303. the specified value for the selected field.  In addition, the operator can
  304. request a "wildcard" search, which looks for any entries in a specific
  305. field that START with a particular string.  The packet op can also request
  306. a summary for any one of the four fields, which is a list of the number of
  307. entries in the database for each distinct value of that field (see below).
  308. The operator can list single records in the database by specifying the
  309. record number.
  310.  
  311.                                 Syntax for Search Requests
  312.  
  313. /1,value<cr> or ?1,value<cr> Searches for "value" in field 1
  314.  
  315. /2,value<cr> or ?2,value<cr> Searches for "value" in field 2
  316.  
  317. /3,value<cr> or ?3,value<cr> Searches for "value" in field 3
  318.  
  319. /4,value<cr> or ?4,value<cr> Searches for "value" in field 4
  320.  
  321. This type of packet instructs the database to look for ALL entries with the
  322. same entry as "value" in the specified field.  The string "value" must
  323. exactly match what was originally typed in for the selected field, with
  324. leading and trailing blanks removed, and without regard for case.  The
  325. initial character of the search request can be "/" or "?" - use whichever
  326. is most convenient.  The two formats are handled identically.  A status
  327. report listing all information for each match is sent back to the
  328. requesting packet station.  The first line gives the search value and the
  329. field number.  At the end of the report, the line:
  330.  
  331.                       "ARES/Data Search done at 1534, nn hits."
  332.  
  333. is sent, which signifies no more information coming, and that "nn" matches
  334. (or hits) were found in the database.
  335.  
  336.     Wildcard Search or Partial Search
  337.  
  338.                     The syntax for a wildcard or partial search is:
  339.  
  340.                                        /n,val*<cr>
  341.  
  342. where "n" is the field number, and "val*" indicates a search for all
  343. entries in fieldn that start with the characters "val".  The response from
  344. the system is identical to that for an exact search request.  This is very
  345. useful if a particular field has been defined to hold more than one piece
  346. of information.  For example, suppose field 1 is defined to be
  347. "Lastname-Firstname" so that Bill Jones would be entered by the line:
  348.  
  349.                  Jones-Bill, shelter3, OK, 444-555-1212, message<cr>
  350.  
  351. Without knowing Mr.  Jones' first name, or whether his data was entered as
  352. "Bill" or "William," one can still search for him in the database by
  353. typing:
  354.  
  355.                                     ?1,Jone*<cr>
  356.  
  357. The database would retrieve all records whose first field began with the
  358. characters "JONE".
  359.  
  360.                                Syntax for Summary Requests
  361.  
  362.          $1<cr>              produces a list of all distinct values
  363.                              for field1, with the number of entries
  364.                              in the database for each
  365.  
  366.          $2<cr>              similar, except summarize on field 2
  367.          $3<cr>              similar, except summarize on field 3
  368.          $4<cr>              similar, except summarize on field 4
  369.  
  370. A Summary Command is provided that prints a breakdown of the number of
  371. like-named items for any particular field.  For example, suppose field 3
  372. were defined to be the shelter name.  After the packet operator types
  373. "$3<cr>", ARES/Data sends a summary on field 3, which may be interpreted as
  374. a list of shelters, with the number of people that have checked in to each
  375. shelter.
  376.  
  377.     Sample Output from a Summary Request
  378.  
  379.          Database summary for Shelter at 1455 on 23
  380.             OAK GROVE            3
  381.             PIONEERHS            20
  382.             EASTVIEW             66
  383.             SHLTR5               37
  384.          ARES/Data done at 1456, found 4 distinct values, entire
  385.          DB has 153 records.
  386.  
  387.     Listing Specific Entries (Records) in the Database
  388.  
  389.                     l nnnn<cr>                  Lists record nnnn
  390.  
  391. Each record is automatically assigned a unique record number for
  392. identification purposes.  The response will be a short header showing the
  393. labels for the various fields, and then the complete information for record
  394. nnnn.
  395.  
  396.           l nnn,mmm<cr>               Lists records numbered from nnn to mmm
  397.  
  398.           l all<cr>                   List ALL records in the database.
  399.  
  400. WARNING:  be careful with this command, as it may cause a large number of
  401. packets to be sent on the channel.  Stop an undesired "list all" by simply
  402. disconnecting from the ARES/Data machine.  This will cause no harm.  Wait a
  403. bit, then just reconnect.
  404.  
  405.                                   Downloading Files
  406.  
  407.                To download a file from the database machine, type:
  408.  
  409.                                   get filename<cr>
  410.  
  411. This facility is intended to be used and controlled by the sysop in the
  412. sense that s/he should tell the remote users what filename to download.
  413. There is no directory facility or anything like that, because such
  414. functions are handled better by a standard mailbox program such as BB (by
  415. AA4RE) or W0RLI.  One file that is provided with ARES/Data is an "info"
  416. file, which gives more information of interest to general users.  If the
  417. sysop has copied this file to the public subdirectory, a station can
  418. download it by typing:
  419.  
  420.                                     get info<cr>
  421.  
  422.                               Conference Bridge (Roundtable)
  423.  
  424. This feature allows any connected station to send messages to other
  425. connected stations or to the sysop.  The conference bridge illustrates how
  426. the ARES/Data system operates as a hub-oriented network, with all
  427. transactions passing through the central database station.
  428.  
  429.     Users Command
  430.  
  431. The users command in the form "users<cr>" or "u<cr>" returns a list of the
  432. callsigns of packet stations currently connected to ARES/Data.  The
  433. response is of the form:
  434.  
  435.                  Users at WN6I-1 (AX0):  N6KL  W6BB-3  W6XYZ  WB6MRQ-7
  436.                  Users at WN6I-4 (DR0):  0:N6KL-3 1:N5BZK 3:AA4RE-12
  437.  
  438. Note that there is one line for each port defined in the ARES/Data system;
  439. who is using which port can be seen.  The callsigns used by ARES/Data for
  440. the verious defined ports do not have to be identical.  After the database
  441. callsign, the port name defined by the sysop during startup is shown in
  442. parentheses.  Note also that for the DRSI packet adapter, several radios
  443. and even several boards can be attached to the database machine.  All the
  444. users connecting to the DRSI adapters are treated as being on one port of
  445. the ARES/Data network.  To refer specifically to the user on DRSI sub-port
  446. 1, put a "1:" in front of the callsign:  "1:N5BZK".  In general, however,
  447. this is not really necessary, since as far as ARES/Data is concerned,
  448. "N5BZK" or "BZK" will do just as well (see below).
  449.  
  450.     Tell Command
  451.  
  452. The Tell command allows connected packet stations to use ARES/Data as a
  453. conference bridge, or roundtable.  The general format is:
  454.  
  455.                 tell callsign message<cr>  OR  t callsign message<cr>
  456.  
  457. For example:
  458.  
  459.                  tell w6bb-3 The food truck just arrived at SJ12<cr>
  460.  
  461. The message "The food truck just arrived at SJ12" is sent to the connected
  462. station W6BB-3 prefaced by a time stamp and the call of the station
  463. originating the tell command.  In this case, if the tell command was sent
  464. by W6XYX, W6BB-3 sees:
  465.  
  466.                    1230 W6XYZ> The food truck just arrived at SJ12
  467.  
  468. It is not necessary to enter the entire callsign--just the suffix or some
  469. other substring will do.  If several connected callsigns contain the
  470. substring, each station will get the message.  The special callsign "*" or
  471. "all" is used to send a message to all connected stations.  The special
  472. callsign "sysop" sends the message to the sysop at the ARES/Data database
  473. station.
  474.  
  475.  
  476.                   EXAMPLES OF HOW TO USE ARES/Data IN SPECIFIC DISASTER
  477.                                       SCENARIOS
  478.  
  479. One of the major virtues of this system is that the meaning of the stored
  480. information is not defined in advance.  In this manner, an ARES/Data system
  481. can be left in unattended operation 24 hours a day, and then be put to use
  482. instantly, in a variety of ways, depending upon the particular disaster or
  483. emergency at hand.  In a given event, the sysop can issue a "labels"
  484. command that gives particular meaning to each of the fields and the
  485. message, so that all know how ARES/Data is being used for that event.
  486.  
  487. In an evacuation, you may want to keep track of evacuees at shelters.  Then
  488. you may want the fields to mean:
  489.  
  490.                  Name, Shelter, Status, PhoneNumber, Contact person.
  491.  
  492. In a multiple-casualty incident, you may want to keep track of victim
  493. transportation.  You may then define the fields to mean:
  494.  
  495.                Triage number, Sex/Age, Ambulance, Hospital, Condition.
  496.  
  497. If you need to maintain a roster for a ham radio staffing situation, the
  498. fields could be:
  499.  
  500.              Call, Name, Location, Shift, phone number for cancellation.
  501.  
  502. If you were in a disaster situation where damage assessment and damage
  503. reports were needed, consider having the following fields:
  504.  
  505.      Coded type of damage, Location, Number of injuries, Callsign, comment.
  506.  
  507. There are many more possibilities, of course.  This is why the exact
  508. definitions of the various fields are not defined in advance.  In any given
  509. situation, more information than will fit into four fields and a comment
  510. field might be needed.  However, on today's 1200 baud packet radio
  511. networks, not much more information per record can be accommodated without
  512. restricting the total number of records that can be handled in a reasonable
  513. time.
  514.  
  515.  
  516.                      HOW TO OBTAIN YOUR COPY OF THE ARES/Data PROGRAM
  517.  
  518. The ARES/Data program, a relative of and successor to the FINDER program,
  519. is available free of charge.  The current version is 1.0, which operates as
  520. described in this paper.  It is possible to download the program via
  521. CompuServe's HamNET in data library 9 and it is also available for
  522. anonymous FTP from the SanJose TCP/IP gateway as file ARESDA10.ARC.  In
  523. addition, a copy of the program along with the documentation is available
  524. for non-commercial, non-profit use from WN6I or N6KL by sending a blank,
  525. formatted 5 1/4" (360 kB) or 3 1/2" (720 kB) floppy in a mailer with return
  526. postage stamps.  The cost to you is the cost of the diskette and postage.
  527. No other compensation can or will be accepted--please do not send money.
  528. We have included a configuration file facility so that you can tailor many
  529. parameters to your specific system.  Of course, you may also obtain
  530. ARES/Data from anyone who already has a copy, and you're encouraged to give
  531. the program to other interested radio amateurs.
  532.  
  533.  
  534.                                      ACKNOWLEDGEMENTS
  535.  
  536. Since the ARES/Data concept is a generalization of the FINDER system, the
  537. deliberations of the FINDER committee in the Santa Clara Valley Section of
  538. the ARRL have contributed to the present form of ARES/Data.  In addition,
  539. our thanks also go to all the ham radio operators in the Santa Clara Valley
  540. Section that have participated in the various alpha and beta tests of the
  541. FINDER and ARES/Data systems.
  542.